数据库角色权限设计方案

#数据库角色权限设计方案| 来源: 网络整理| 查看: 265

数据库角色权限设计方案_sql数据库角色成员身份思创斯忠实用户-ss • 2023年1月11日 18:15 • 未分类

数据库角色权限设计方案_sql数据库角色成员身份在任何系统中，权限设计是最基础的东西，本文给出一个基于角色的权限设计的循序渐进的设计方案。　　在权限系统中，功能（权限）是最小的单位，比如起草新闻、编辑新闻、审核新闻、删除新闻等，而角色是一类功能的集合，比如新闻编辑这个角色，他可能有起草新闻、编辑新闻等功能集合，而责任编辑他可能就有更多的权限，比如除了新闻编辑的功能，还有审核新闻、删除新闻等功能，给张三赋予新闻编辑的角色（其实我更愿意说把

大家好，我是你的好朋友思创斯。今天说一说数据库角色权限设计方案_sql数据库角色成员身份,希望您对编程的造诣更进一步.

　在任何系统中，权限设计是最基础的东西，本文给出一个基于角色的权限设计的循序渐进的设计方案。

　　在权限系统中，功能（权限）是最小的单位，比如起草新闻、编辑新闻、审核新闻、删除新闻等，而角色是一类功能的集合，比如新闻编辑这个角色，他可能有起草新闻、编辑新闻等功能集合，而责任编辑他可能就有更多的权限，比如除了新闻编辑的功能，还有审核新闻、删除新闻等功能，给张三赋予新闻编辑的角色（其实我更愿意说把张三加入到新闻编辑这个角色中去），张三就可以起草新闻、编辑新闻了，给李四赋予责任编辑的角色，李四就可以起草新闻、编辑新闻、审核新闻、删除新闻了。

　　我们来看看版本一的解决方案：

　　我们来模拟一下上面的数据：

　　用户信息表：

UserID

UserName

张三

李四

　　角色表：

RoleID

RoleName

新闻编辑

责任编辑

　　角色用户表：

RoleID

UserID

　　功能表：

FunctionID

FunctionName

起草新闻

编辑新闻

审核新闻

删除新闻

　　角色功能表：

RoleID

FunctionID

　　我们来看看如何判断一个用户具有某个功能权限：

　　首先在用户张三登录的时候，获取张三的全部功能列表：

Select FunctionID From 角色功能表 Where RoleID In (Select RoleID From 用户角色表 Where UserID=’U1’)

　　这样就可以得到张三的全部功能列表Functions，在起草新闻的页面我们就可以做如下判断：

Functions.Contain(‘F1’);//当然你可以把这个’F1’定义成一个常量：NewsFunction.Draft

　　如果为true就说明张三有起草新闻的权限。

　　当然对于web应用，您可以把Functions 用session保存起来，以避免每打开一个页面都去数据库中获取。

　　似乎看起来是一个不错的解决方案。

　　还是新闻系统，最初新闻系统没有分类，但是随着新闻的增加，没有分类的新闻看起来总是乱的，于是张三和李四给新闻添加了分类A、分类B，还是由张三负责起草，李四负责审核，以后又添加了更多的分类，并且也增加了人手，这个时候就有新的要求出来了：希望张三只负责分类A的起草，分类B的起草交给其他人做，李四呢也只负责分类A的审核（就相当于是一个栏目的责任编辑）。

针对这样的需求，版本一就无能为力了（当然你也可以增加几个功能：比如分类A的新闻起草和分类B的新闻起草，再把这个功能添加到相应的角色里面去，但是这个应该不是我们要得解决方案吧，不过版本二也是基于这个思想来解决的）。

其实比新闻更好的例子是论坛板块的版主。

下面是版本二的解决方案：

在版本二的功能表中加入了一个ResourceType这个字段，这个字段用来表示对某个资源的分类（比如新闻），我们同样来模拟一下（新闻分类A的ResourceType为：NTA，分类B为：NTB）：

功能表：

FunctionID

ResourceType

FunctionName

NTA

起草新闻：分类A

NTA

编辑新闻：分类A

NTA

审核新闻：分类A

NTA

删除新闻：分类A

NTB

起草新闻：分类B

NTB

编辑新闻：分类B

NTB

审核新闻：分类B

NTB

删除新闻：分类B

然后在角色表添加相应的角色，在角色功能表中添加对应的功能。

获取Functions的语句也相应地做变化：

Select FunctionID + ‘，’ + ResourceType From 角色功能表 Where RoleID In (Select RoleID From 用户角色表 Where UserID=’U1’)

权限的判断也就变成：

Functions.Contain(‘F1,NTA’);

在新添加一个分类的时候，同时也在功能表中增加相应的记录（当然不是在数据库里面直接添加，由和功能相关的函数来添加）。

使用这种解决方案可以简单地对有分类的应用（比如论坛系统）的每个分类实行不同的控制（比如VIP板块，就只能拥有VIP角色的用户才能浏览、发表等，而其他板块只要是注册用户就可以使用了）。

在实际应用中FunctionID并不是随便的一个字符串，而是进行了编码，其编码中包含了模块ID以及能够体现出父子关系，举个例子来说：对于论坛系统，我们给它一个模块ID为”30”，论坛的功能我们先分成2类，一类是管理类（比如删除帖子），一类是使用类（比如发帖、回帖、浏览帖子等），给管理类一个编码：01，使用类一个编码：02，我们就对FunctionID进行如下的编码：

300101：删除帖子

300201：发帖

300202：回帖

300203：浏览帖子

对于资源（比如某个板块1，板块的ID为：01），我们可以组合出如下的Functions（当然这个组合你也可以不用逗号分隔，用其他的组合方式也可以，不过不要产生歧义）：

300101,01：板块1删除帖子的功能

300201,01：板块1发帖的功能

……

对于RoleID也是采用的编码方式，也能体现角色的父子关系，也可以实现角色功能的继承等（当然获取角色功能列表的SQL语句就不是现在这么简单了）。在我现在的应用里面没有实现角色的继承（虽然角色的编码体现出了角色的父子关系）。

转载：http://tubo.cnblogs.com/archive/2005/09/02/228828.html

权限管理

权限管理，主要是人员和权限之间的关系，但是如果让人员直接和权限打交道，那么权限的赋值、权限的撤销以及权限的变动会非常的麻烦，这样引入了，角色，给角色赋权限，然后给用户分配角色。

这个设计主要涉及6张表，

用户表,（用于存储用户的所有信息）

权限表，（用于存储所有的权限）

角色表，（用于存储所有的角色）

用户和角色的关联表，（用户和角色的关联）

角色和权限的关联表，（角色和权限的关联）

菜单表，（里面关联了权限，主要是现实用的）

用户表

代码 CREATE TABLE [ dbo ] . [ Users ] ( [ UserID ] [ int ] IDENTITY ( 1 , 1 ) NOT NULL , [ UserName ] [ nvarchar ] ( 50 ) primary key , -- 帐号 [ Password ] [ nvarchar ] ( 50 ) , [ UserDspName ] [ nvarchar ] ( 50 ) , [ Sex ] [ char ] ( 1 ), [ Birthday ] [ datetime ] , [ Phone ] [ nvarchar ] ( 20 ) , [ Email ] [ nvarchar ] ( 100 ), [ EmployeeID ] [ nvarchar ] ( 20 ) , [ Activity ] [ bit ] , -- 是否可用 [ UserType ] [ char ] ( 2 ) , [ Style ] [ nvarchar ] ( 50 ))

权限表：

CREATE TABLE [ dbo ] . [ Permission ] ( [ PermissionID ] int identity , [ Description ] [ nvarchar ] ( 50 ) -- 权限名称 )

角色表：

CREATE TABLE [ dbo ] . [ Roles ] ( [ RoleID ] [ int ] IDENTITY , [ Description ] [ nvarchar ] ( 200 ) -- 角色名称 )

用户和角色的关联表：

代码 CREATE TABLE [ dbo ] . [ UserRoles ] ( [ UserID ] [ int ] NOT NULL , -- 用户ID [ RoleID ] [ int ] not null , -- 权限ID CONSTRAINT [ PK_UserRoles ] PRIMARY KEY CLUSTERED ( [ UserID ] ASC , [ RoleID ] ASC ) WITH (IGNORE_DUP_KEY = OFF ) ON [ PRIMARY ] ) ON [ PRIMARY ]

角色和权限的关联表：

代码 CREATE TABLE [ dbo ] . [ RolePermissions ] ( [ RoleID ] int NOT NULL , -- 角色ID [ PermissionID ] int NOT NULL , -- 权限ID CONSTRAINT [ PK_RolePermissions ] PRIMARY KEY CLUSTERED ( [ RoleID ] ASC , [ PermissionID ] ASC ) WITH (IGNORE_DUP_KEY = OFF ) ON [ PRIMARY ] ) ON [ PRIMARY ]

菜单表：

代码 CREATE TABLE [ dbo ] . [ menu ] ( [ ID ] [ int ] IDENTITY ( 1 , 1 ) NOT NULL , [ TextCH ] [ nvarchar ] ( 100 ) NULL , -- 菜单的中文显示 [ TextEN ] [ nvarchar ] ( 200 ) NULL , -- 菜单的英文名称 [ ParentID ] [ int ] NULL , -- 父节点 [ orderID ] [ int ] NULL , -- 同一个父节点下面的排序 [ Url ] [ nvarchar ] ( 200 ) , -- 菜单对于的权限 [ PermissionID ] [ int ] NULL , -- 权限ID [ ImageUrl ] [ nvarchar ] ( 50 ) NULL -- 菜单图片链接 ) ON [ PRIMARY ]

以上便是所有的数据库结构，代码正在实现中；

最后权限的最终呈现和表现是通过菜单来实现的，个人感觉粒度太大了（最小是页面），现在我想知道能否将权限加到某一个按钮上面，请大家指点

转载：http://blog.itpub.net/16436858/viewspace-627049/

文章由思创斯整理,转载请注明出处：https://ispacesoft.com/42218.html

数据设计赞 (0)

思创斯忠实用户-ss 0 0 生成海报

【本文地址】

数据库角色权限设计方案

数据库角色权限设计方案

今日新闻

推荐新闻